Methods and systems for online self-service receivables management and automated online receivables dispute resolution

ABSTRACT

A computer-implemented and Internet-based method of managing Accounts Receivable (AR) information includes steps of receiving a customer request for remote Internet access to AR information (such as pending invoices) owned by vendor; retrieving the customer&#39;s AR information from a database and enabling the retrieved AR information to be remotely displayed for the customer and enabling the vendor&#39;s internal personnel to retrieve and to display the customer&#39;s AR information simultaneously as the AR information is displayed for the customer. The customer may dispute an invoice accessed from the database by accessing the vendor&#39;s Web site and by selecting a reason code for the dispute and at least a disputed amount to create a pending Credit Memo Request, all without direct manual involvement from the vendor. The pending Credit Memo Request may then sent to and routed through a selected process for the selected reason code, a selected hierarchy of persons empowered to approve Credit Memo Request incorporating the selected reason code and/or a primary approver for the selected reason code. Upon approval of the Credit Memo Request, a Credit Memo may be automatically generated and the disputed amount may be credited to the disputed invoice. The customer may be notified of the approval or rejection of the Credit Memo Request, as may be selected personnel internal to the vendor. Real time balances may be available to the customer on a self-server basis, as are other common AR-related services.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] This invention relates to computer-implemented systems andmethods for self-service management of Accounts Receivables (AR) over acomputer network, such as the Internet. This invention also relates tocomputer-implemented and Internet-based systems and methods for thedisputing one or several invoices in a deploying company's AR system.

[0003] 2. Description of the Related Art

[0004] Each year, analysts project increased growth in both the volumeand the value of online transactions over the World Wide Web (hereafter,the “Web”). Every year, the actual volume and value of the goods andservices transacted over the Web has exceeded these projections. As theworld becomes increasingly mobile, wireless and connected, seamless andcomplete Web connectivity has revealed itself to be central toprocessing transactions faster, easier, at lower costs and at higherprofit margins.

[0005] The increasing ubiquity of the Web in commercial transactions hasled companies to examine their business processes closely, to evaluatetheir effectiveness and to develop possible improvements. AccountsReceivables is one area that has yet to benefit from a comprehensiveoverhaul to take advantage of the possibilities offered by the Internet.Indeed, AR is conventionally handled by a variety of means, the mostfundamental being the paper invoice sent by a vendor to its customer.Customers need to manage their AR accounts with each vendor, althoughthey may not perceive their actions as AR management. Traditionally,such AR management includes contacting the vendor's customer service orcollections department over the telephone, email or facsimile for eachquestion and each request. The vendor would then retrieve the customer'sdata and perform some action, whether it is to provide the customer witha copy of an invoice or create and process a Credit Memo Request, forexample. Other common customer requests and questions include requestsfor an account balance, inquiries related to payments being applied toinvoices, requests for amounts past due, inquiries asking whether allcredits have been applied to the proper account, for example. Respondingto these requests and questions is traditionally a burdensome manualprocess for both parties involved in the transaction. The vendor mustdedicate substantial HR resources to their AR department and thecustomer expends time and money repeatedly performing transactions thatdo not positively contribute to their bottom line.

[0006] This administrative burden, moreover, disproportionably rests onthe shoulders of the vendor, as it must repeatedly collect, process andanalyze data provided by each of its customers in order to satisfy thecustomers' requests or respond to the customers' questions. However, asbetween the customer and the vendor, it is the customer that often hasthe superior (most accurate, most up to date) information. Indeed, thecustomer knows why she deserves a credit or knows which invoice isduplicate, for example. There is believed to have been a long felt need,therefore, for methods and systems that enable customers self-serviceaccess to their AR information. Self-service access to AR informationwould improve communications between customer and vendor, would reducecosts and improve both the quality and timeliness of the servicesprovided. Enabling self-service access to vendor AR information woulddecrease the administrative burden of fielding the wide range ofcustomer requests and questions and would improve collections and cashflow and enable the vendor to focus on strategy, rather thanadministration. When an organization is focused on strategy, rather thanon trying to keep up with volume of data entry and customer requests,costs decrease and efficiency increases. Eventually, a smaller percentof the vendor's time may be spent on transaction control and processing,and more time may be spent on activity planning, optimizing, andanalyzing. Thus, by enabling self-service access to AR information andby correspondingly freeing up data processing resources, the vendors'finance departments may undergo a transformation from a mere processingcenter to a full-fledged strategic planning center.

[0007] Self-service access to AR information, however, would only freethe vendor from the more mundane tasks traditionally associated withresponding to customers' inquiries and questions. The resolution ofinvoice and account disputes constitutes another significant drain onhuman resources within a typical AR department. Indeed, customers mustbe able to communicate disputes to their vendors. Such disputes must betracked and resolved. Traditionally, customers would “manage” suchdisputes indirectly: they would call the vendor's sales representative,customer service or collections department and verbally explain thenature of the dispute. Such a dispute processing methodology is wastefulin both time and resources to both parties to the dispute. What areneeded, therefore, are methods and systems to allow customers toinitiate disputes without active manual involvement form the vendor.

SUMMARY OF THE INVENTION

[0008] An object of the present invention, therefore, is to providemethods and systems for remote self-service access to AR information.Another object of the present invention is to provide customers with themeans to dispute an account balance or an invoice online.

[0009] In accordance with the above-described objects and those thatwill be mentioned and will become apparent below, a computer-implementedand Internet-based method of managing Accounts Receivable (AR)information, according to an embodiment of the present invention,comprises the steps of receiving a customer request for remote Internetaccess to AR information that is owned by a deploying company;retrieving the customer's AR information from a database and enablingthe retrieved AR information to be remotely displayed for the customerand enabling personnel at the deploying company to retrieve and displaythe customer's AR information at any time, even simultaneously as the ARinformation is displayed for the customer. Most any number of customers,moreover, may access their AR information at any time. In addition, mostany number of internal AR personnel may access the AR information at anytime (24 hours a day, 7 days a week), even simultaneously as thecustomers are accessing the same AR information.

[0010] According to further embodiments, the AR information may bedisplayed on a World Wide Web (Web) browser or other suitableapplication. Keyword searching of the AR information stored in thedatabase may be enabled through a Web browser to retrieve anyinformation stored in the database that matches an entered searchcriteria, irrespective of a category in which the information is storedin the database. The keyword searching may allow restricted searchingbased on an amount range, date range, due date range, category,customer, customer location, applied payments, open items, closed items,pending items, Credit Memo Requests, Credit Memos, a document numberand/or any data categorization the database. The keyword searchingacross all customer AR information may be restricted to personnel of thedeploying company. The retrieved AR information may include invoiceinformation that is optimized for printing in a format that matches aformat of a corresponding paper invoice. A step of restricting access tothe AR information by the personnel of the deploying company to selectedpersonnel may also be carried out. The selected personnel may include,for example, collectors, accountants, AR personnel of the deployingcompany and/or sales personnel.

[0011] A step of enabling customers to dispute one of all and a portionof an invoice and to create and submit a Credit Memo Request may alsoform part of the above-described method. To do so, a plurality of reasoncodes for disputing the invoice may be provided, each of the reasoncodes being mapped to a corresponding user interface, the user interfacedisplaying only information specific to its corresponding reason code.Each of the reason codes may include a flag that determines whether thereason code is visible only to personnel of the deploying company or isvisible to both the personnel of the deploying company and to thecustomers external to the vendor. The reason codes visible only to thepersonnel of the deploying company may include bankruptcy and goodwill,for example. The reason codes visible to the customers may includefreight, tax, shipping, duplicate invoice and/or a specific invoiceline, for example.

[0012] The method may implement a workflow engine, the workflow enginedefining and enforcing a hierarchical routing of the Credit Memo Requestas the Credit Memo Request is processed by the deploying company. A stepof automatically generating a Credit Memo Request and updating thecustomer's AR information in real time when the Credit Memo Request isapproved may also be carried out. The workflow engine may carry out astep of notifying the customer and/or selected personnel of thedeploying company when the Credit Memo Request is approved and acorresponding Credit Memo is generated. The notifying step may becarried out by email and/or by updating a Web site, for example. A stepof marking an invoice against which a Credit Memo Request has beensubmitted may be carried out.

[0013] The customer request for remote access may include customerauthentication data, which may, for example, be stored in the customer'scomputer system as a cookie. The retrieved and displayed customer ARinformation may include a summary screen summarizing the customer's ARinformation. The method may also include the step of hyperlinking someor all of the summarized AR information on the summary screen to enablethe customer to view detailed AR information corresponding thehyperlinked summarized AR information. The retrieved and displayed ARinformation may include information related to invoices, payments,Credit Memos applied to a particular invoice, Credit Memos applied to anentire customer account and/or Credit Memo Requests, for example. Thedisplayed AR information may be dynamically sortable and the method mayfurther comprise the step of sorting and re-displaying the displayed ARinformation. The appearance of the displayed AR information may becustomizable to match the corporate identity of the deploying company.The displayed AR information may include a first portion (such as thetop portion) and a second portion (such as the bottom portion), thefirst portion displaying static AR information including customer name,customer number and the second portion displaying dynamic AR informationthat changes depending upon an action by the customer. The secondportion may be adapted to include invoice information and configurablemessages from the deploying company. A step of displaying a button alongwith the displayed AR information may be carried out, wherein clickingon the button causes all activities associated with a currentlydisplayed item to be displayed.

[0014] The present invention is also a computer-implemented andInternet-based method of disputing an invoice from a vendor to acustomer, comprising the steps of accessing a database recordcorresponding to the invoice to be disputed over a Web site of thevendor; selecting a reason code for the dispute along with anidentification of a disputed amount; validating a Credit Memo Requestincorporating the selected reason code and the disputed amount to createa pending Credit Memo Request; causing the Credit Memo Request to besent to and routed through at least one of a selected process for theselected reason code, a selected hierarchy of persons empowered toapprove Credit Memo Request incorporating the selected reason code and aprimary approver for the selected reason code and receiving anotification upon approval or rejection of the pending Credit MemoRequest, the disputed amount being automatically credited to thedisputed invoice when the pending Credit Memo Request is approved.

[0015] According to still further embodiments, the selecting step mayselect a reason code from among a group of reason codes includingfreight charges, taxes, shipping charges, duplicate invoice, specificinvoice line and at least one vendor-defined reason code, for example.When the selected reason code does not fit a reason for requesting theCredit Memo, the selecting step may further include a step of addingexplanatory comments to a blank field, thereby enabling the establishedhierarchy of persons empowered to approve the validated Credit MemoRequest and the primary approver for the selected reason code to processthe Credit Memo Request. The is validating step may include a step ofsubmitting the Credit Memo Request if the Credit Memo Request is correctand may include the step of correcting the Credit Memo Request if anyinformation appearing thereon is incorrect. The validating step mayinclude a step of displaying the Credit Memo Request for the customerand giving the customer a first option to submit the Credit Memo Requestto execute the causing step and a second option to return to an earlierscreen to correct any incorrect information on the Credit Memo Request.The reason codes, process, hierarchy and primary approver may be definedby the vendor upon enabling the computer-implemented method. A step ofauthenticating a customer before allowing the customer to carry out theaccessing step may also form part of the method. A step of accessing acurrent status of the pending Credit Memo request in real time may alsobe carried out. The method may further include a step of marking thedisputed invoice with a legend or indicia indicating that a Credit MemoRequest is pending there against.

[0016] The present invention, in another aspect thereof, is anInternet-based electronic system for enabling remote access andmanagement of Accounts Receivable (AR) information of a deployingcompany, comprising a database that configured to store the ARinformation; a first computer arranged to receive a customer request forremote Internet access to the AR information, to retrieve the ARinformation from the database upon receiving the customer request and toenable the retrieved AR information to be remotely displayed for therequesting customer; a second computer arranged to enable personnel atthe deploying company to retrieve and display the customer's ARinformation at any time, even simultaneously as the AR information isdisplayed for the customer.

[0017] The AR information may be displayed on each of the first andsecond computers using a World Wide Web (Web) browser or other suitable.Each of the first and second computers may is be further arranged tocarry out keyword searching of the database through a Web browser toretrieve any information stored in the database that matches an enteredsearch criteria, irrespective of a category in which the information isstored in the database.

[0018] The present invention may also be viewed as an Internet-basedelectronic system for disputing an invoice from a vendor to a customer,comprising a database configured to store the invoice; a computeradapted to connect to the Internet; a Web site, the Web site beingcontrolled by the vendor and accessible by the computer, the Web sitebeing configured to allow a customer using the computer to remotelyaccess the invoice and to dispute the invoice by: selecting a reasoncode for the dispute and at least a disputed amount; validating a CreditMemo Request incorporating the selected reason code and the disputedamount to create a pending Credit Memo Request, and causing the CreditMemo Request to be processed through a workflow engine to send and routethe Credit Memo Request through at least one of a selected process forthe selected reason code, a selected hierarchy of persons empowered toapprove Credit Memo Request incorporating the selected reason code and aprimary approver for the selected reason code.

[0019] The workflow engine may further be configured to send anotification upon approval or rejection of the pending Credit MemoRequest, the disputed amount being automatically credited to thedisputed invoice when the pending Credit Memo Request is approved. TheWeb site may also allow the customer to add explanatory comments to ablank field, to enable the selected hierarchy of persons empowered toapprove the validated Credit Memo Request and the primary approver forthe selected reason code to process the Credit Memo Request when theselected reason code does not fit a reason for requesting the CreditMemo Request. The Web site may is also enable the submission of theCredit Memo Request if the Credit Memo Request is correct and thecorrection of the Credit Memo Request if any information therein isincorrect. The reason codes, process, hierarchy and primary approver maybe predefined by the vendor. The Web site may further be configured toauthenticate a customer before allowing the customer to access theinvoice. Real time access to the status of the pending Credit Memorequest may also be available through the Web site of the presentinvention. The disputed invoice may be marked with a legend or indiciaindicating that a Credit Memo Request is pending there against.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] For a further understanding of the objects and advantages of thepresent invention, reference should be made to the following detaileddescription, taken in conjunction with the accompanying figures, inwhich:

[0021]FIG. 1 is a diagram of a system and method for online self-serviceaccounts receivable management, according to an embodiment of thepresent invention.

[0022]FIG. 2 is a representation of an “Account Details” Web page,according to an embodiment of the present invention.

[0023]FIG. 3 is a diagram detailing a logical organization and task flowof the online accounts receivable system according to an embodiment ofthe present invention.

[0024]FIG. 4 is a flow chart of a method of initiating and automaticallyprocessing a dispute over an invoice from a vendor to a customer throughthe creation and processing of a Credit Memo Request, according to anembodiment of the present invention.

[0025]FIG. 5 is a block diagram of a computer suitable for implementingthe present invention.

DESCRIPTION OF THE INVENTION Functional Description

[0026] The present invention, according to an embodiment thereof, is acomputer-implemented and Internet-based method of managing AccountsReceivable (AR) information. The present invention allows a customer toremotely access his or her account information in the vendor's ARdatabase and allows the vendor's internal personnel to simultaneouslyaccess the same account information as is accessed by the customer. Thepresent invention, moreover, allows the customer to carry out selectedactions on the accessed AR information, such as to pay an invoice, toobtain a duplicate invoice, to check whether a payment has posted to anaccount, to dispute any portion of an invoice, and the like, all withoutintervention from the vendor's accounts receivable department or thevendor's customer service department. FIG. 1 is a diagram of a system100 and method for online self-service AR management, according to anembodiment of the present invention. As shown therein, the system 100may include one or more servers 114 that are configured to run anInternet application embodying aspects of the present invention. Theserver(s) 114 is coupled to a network 112 that includes, for example,the Internet. The server 114 also has access to the AR database 110 ofthe company deploying the method and system of the presentinvention—that is, the vendor. According to the present invention, theInternet application embodying the present invention and the ARinformation database 110 are accessible to two classes of users. Thefirst class of such users includes the vendor's internal personnel. Suchinternal personnel (collectively represented in FIG. 1 as computer 116)includes accountants, customer service personnel, and collectorsassigned to insure timely collection of outstanding receivables for thevendor and all other personnel that require access thereto. For example,such internal personnel 116 may also include a sales person assigned tothe customer, as the compensation of such employees may be tied to bothsales and collections. Although the present invention allows thevendor's internal personnel access to the AR information, the userinterface, according to one embodiment, is optimized for customeraccess, and may not be optimal for large-scale data entry. Thus, thepresent invention may function in concert with one or more other coreaccounts receivables applications more suited to large-scale data entrytasks.

[0027] The second class of users is the vendor's customers, collectivelyrepresented in FIG. 1 as computer 120. According to the presentinvention, the customer 120 may remotely log onto the server 114 overthe network 112, preferably using a secure communication protocol, suchas Secure Socket layer (SSL), for example, over the World Wide Web(hereafter “Web”). According to an embodiment of the present invention,both the customer 120 and the vendor's own internal users 116 log ontothe server 114 using commonly available browser software, such asNetscape Navigator, or the like.

[0028] Upon being properly authenticated, the customer 120 may be sentto an “Account Details” Web page. The Account Details Web page 200,shown at FIG. 2, allows the customer to view, in a tabular format, allof his or her outstanding invoices, account balances, etc. Theinformation displayed in the Accounts Details page is particular to thelogged-on customer only. The level of security (access to customerinformation) may be controlled by the system administrator of thedeploying company (the vendor's system administrator, for example) whenassigning user names and user passwords to its customers 120. Accordingto an embodiment of the present invention, the Web pages displayed aredynamic in nature and may vary depending upon user input. For example,as shown in FIG. 2, each of the column headings 212 may be determined bythe nature of the information displayed. Each of the column headings mayinclude, for example, an up or down arrow 210. This feature allows theuser to sort the displayed data in ascending or descending order (i.e.,either numerically or alphabetically). Additional columns may be addedto the Account Details page of FIG. 2, and columns may be removedtherefrom, at the user's option. Therefore, instead of capturing thedata and exporting it to a separate spreadsheet for analysis, the user120, according to the present invention, may dynamically re-configurethe displayed information to suit his or her needs. To accomplish this,Hyper Text Markup Language (HTML) and/or Dynamic Hyper Text markupLanguage (dHTML) may be used, as set forth, for example, in Musciano &Kennedy, HTML The Definitive Reference, 3^(rd) Edition, © 1998, O'Reilly& Associates and Goodman, Dynamic HTML: The Definitive Reference, ©1998, O'Reilly & Associates, the entire text of each being incorporatedherein by reference.

[0029] For ease of reference, many or all of the entries in the AccountDetails page of FIG. 2 may be hyperlinked, to allow the user to “drilldown” to see additional information on the selected entry. For example,the invoice 123432 in FIG. 2 may be selected by the click of a pointingdevice, (such as a mouse, for example) and the underlying invoice wouldbe displayed on the user's browser, in printable format, as shown at 118in FIG. 1. As many different records may be displayed in the AccountDetails screen 200, Web-style pagination may advantageously be employed.For example, the first 10 records may be initially displayed on theAccount Details page, and subsequent groups of 10 may be sequentiallydisplayed by clicking an appropriate link thereto. To assist the user120 in finding the invoice or other item of interest, searchingcapabilities are included, as shown at reference numerals 214 in FIG. 2.According to the present invention, a keyword search may be carried outto search for any record, using any field. For example, a searchcriteria entered in the search window 216 will cause the search engineto search all of the customer's records containing the matchingcriteria, irrespective of a category in which the information is storedin the database.

[0030] For example, entering “O-921” in the search window 216 will causethe retrieval of the records for invoices 10813 and 10809, as bothinclude the matching criteria “O-921” in the “Sales Order” column. Thesearch may be further narrowed by limiting the search to only certainitems, such as all overdue invoices, using pull-down menu 218. Byselecting “Advanced Search”, also shown at 214, the user 120 may limitthe search even further by specifying, for example, an amount range, adue date range and/or a date range, for example. Wildcard searching,such as in the keyword “108**” (wherein the symbol “*” represents anycharacter) is also supported in the present invention, and such akeyword will return invoices 10813 and 10809, as both invoices beginwith the digits “108”. Preferably, real time account and/or invoicebalances are displayed, as shown at 220 in FIG. 2.

[0031] Whereas the customer 120 may search only within his or her own ARinformation, as shown in the Account Details page of FIG. 2, thevendor's own internal AR personnel (116 in FIG. 1) may, depending uponan assigned permission level, search the entire database 110, acrosscustomers 120. Thus, when one of the vendor's AR personnel, for example,enters a search criteria of “123432”, as shown at 216, all recordscontaining “123432” may be retrieved, including that of invoice 123432,as shown at 118 in FIG. 1.

[0032] As shown in FIG. 1, both the vendor's AR personnel 116 and thecustomer 118 may both simultaneously access the same AR information; inthis example, a screen representation of invoice number 123432, as shownat 118. In practice, this means that one of the vendor's collectors 116and the customer 120 may both look at the same invoice at the same time.For example, the customer 120 may have a question about his or herinvoice that cannot be addressed by the self-service features of thepresent invention, or may require some additional assistance. In thatcase, the vendor's collector 116 and the customer 120 may engage in atelephone conversation while looking at the same information at the sametime, displayed on their respective computers' Web browsers. This maygreatly simplify addressing the customer's concerns while simultaneouslyeducating the customer as to the capabilities and functionality of theAR system according to the present invention.

[0033]FIG. 3 is a diagram detailing a logical organization and task flowof the online accounts receivable system 300 according to an embodimentof the present invention. As shown therein, the system 300 may include aplurality of users 302, 304 and 306. The users 302, 304 and 306 includeboth internal AR personnel of the deploying company (accountants,collectors, etc.) and customers. Each of the users 302, 304 and 306 mayaccess the login page 310 of the AR application embodying the presentinvention via the network 308. After being properly authenticated, theuser 302, 304, 306 may be presented the Account Details page 312, asshown in FIG. 2 if the user 302, 304, 306 is a customer and, if the user302, 304, 306 is internal to the vendor, may be presented with a searchpage allowing the user 302, 304, 306 to search the entire database 110,across all customers. From either the Account Details 312 or the searchpage (not shown), the user 302, 304, 306 may access a number of otherpages 314, 316, 318, 320, 326 or 330, each of which allowing the user302, 304, 306 to carry out respectively different actions. Starting withthe interactive Invoice page 314, the customer's invoice may bedisplayed in a manner similar to that shown at 118 in FIG. 1; that is,in a manner that resembles a paper invoice the user 302, 304, 306 mayhave received. The invoice information (the AR information) may beadvantageously printed in HTML and/or dHTML to create a printable page.Such a printed invoice may advantageously include the invoice headerinformation, balance and invoice lines. From the Interactive Invoicepage 318, the user 302, 304, 306 may be presented with the opportunityto print the invoice, dispute the invoice, pay the invoice by creditcard or other payment instrument, apply a previously made payment to beinvoice and/or to view past activities on the displayed invoice. Morethan one invoice may be displayed at a time, and each invoice may openin a separate new window on the user's browser.

[0034] If, as shown at 324, the user 302, 304, 306 wishes to submit apayment, he or she may be sent to the Credit Card Payment Confirmationpage 326, whereupon the user 302, 304, 306 may be prompted to enter therelevant information to enable payment of an invoice by credit card orother payment instrument. After verifying the payment information, theuser 302, 304, 306 may be presented with a printable paymentconfirmation page. Alternatively, the user 302, 304, 306 may select theInteractive Payment page 318, whereupon the user 302, 304, 306 may bepresented with a page displaying payment header information, such as thedate the payment was received, the amount of the payment, the bankaccount from which payment was drawn, and the like. Receipt applicationmay also be displayed. This page may also be displayed in a formatsubstantially like the printed version thereof. The user 302, 304, 306may also select to view any Credit Memos (CM) that may be tagged totheir account, as shown at reference 320 in FIG. 3. Such credit memosmay be printed for the customer's records and/or applied to thecustomer's account and/or to a specific pending invoice (if not alreadyapplied to their account and/or an invoice). From either the InteractivePayment page 318 or the On Account CM page 320, the user 302, 304, 306may choose the “Apply” option (i.e., click on a button labeled “Apply”or otherwise select the “Apply” option). Doing so may send the user 302,304, 306 to an Apply Payment Web page, in which the user 302, 304, 306may search for any unapplied payments he or she may have made, maysearch for a selected invoice and may apply the unapplied payment to theselected invoice and/or to the customer's account.

[0035] According to an embodiment of the present invention, the user302, 304, 306 may dispute all or a portion of an invoice submitted by avendor. To do, so, the customer 302, 304, 306 may click on or otherwiseselect the “Dispute” option, as shown at 332 in FIG. 3. After submittingthe necessary information to create a Credit Memo Request (CMR), thecreated CMR is processed and routed according to a CMR workflow engine,as shown at 328 and a confirmation thereof may be printed at the pagereferenced by 330, which may also accessible from the Account Detailspage. 312. When and if a Credit Memo is issued on the underlying CreditMemo Request, the user 302, 304, 306 may view and/or reprint the CreditMemo, as shown at 316.

[0036] A methodology for disputing an account and/or an invoice,according to an embodiment of the present invention, is set forth indetail below, with reference to FIG. 4. The reasons for disputing a billare many, and include such reasons as returned items, no credit givenfor a returned item, invalid amounts, invalid taxes, freight, duplicateinvoice, incorrect freight charges, and the like. Rather than requiringthe customer 302, 304, 306 to telephone or fax the vendor's collectiondepartment, the present invention allows the customer 302, 304, 306self-service access to the process of creating a Credit Memo Request.Indeed, it is the customer 302, 304, 306 that knows why a Credit Memoshould be entered against their account or a specified invoice. Thepresent invention, therefore, allows the customer 302, 304, 306 toinitiate the process of creating such a Credit Memo request that, ifapproved, will result in the automatic is generation of a Credit Memo.In turn, the Credit Memo will automatically credit the customer'saccount(s) and/or a specified invoice or invoices for the requestedamount. Customers 302, 304, 306 are thus given an extensive ability toinitiate and track their disputes, while vendors are given the tools tocompletely bind together and automate the processes for the creation andresolution of Credit Memo Requests.

[0037] As shown in FIG. 4, if a customer 302, 304, 306 wishes to disputean invoice and/or an account (step S1), he or she may be prompted toselect one of a plurality of predefined reason codes, as shown in stepS2 a. The plurality of predefined reason codes may include codes fordisputing freight charges, as shown at S2 a 1, disputing taxes appliedas shown at S2 a 2, disputing a specific invoice line, as shown at S2 a3 or disputing a duplicate invoice, as shown at S2 a 4, for example.Other reason codes may readily be defined, as each deploying company(e.g., vendor) may allow invoices and/or accounts to be disputed forreasons other than shown in FIG. 4. The customer 302, 304, 306,moreover, may be given the opportunity to enter explanatory commentsregarding the requested Credit Memo Request. It is preferable that theentire universe of reason codes be defined, as there is preferably no“Other” reason code. Indeed, it is preferable to fit the dispute intoone of the plurality of predefined reason codes, so as to allow theautomatic processing thereof, as it may be difficult to automate theprocessing of a Credit Memo Request in which the reason for theunderlying dispute has not been clearly defined. A pull down menu mayinclude a listing of all of the reason codes that may be utilized.However, there may be instances wherein the reason code selected doesnot precisely define that portion of the invoice that is to be disputed.For those reason codes, additional nested pull down menus may beprovided, which prompt the user to specify the invoice portion that isthe subject of the dispute. Reason codes S2 a 1, S2 a 2, S2 a 3 and S2 a4 are examples of dispute reason codes that may be visible to thecustomer 302, 304, 306. However, not all reason codes need be visible onthe Web page displayed to the customer 302, 304, 306. Indeed, the vendormay have other reasons for granting a Credit Memo Request, such asgoodwill to a particularly valuable or loyal customer, as shown at S2 b1 or the bankruptcy of the customer 302, 304, 306, as shown at S2 b 2.Such reason codes would be visible and selectable only to the ARpersonnel of the deploying company (vendor), as determined by the loginprofile of the user (saved in the user's computer as a cookie, forexample). Other reason codes that are not visible to the customer 302,304, 306 may also be predefined. A flag may be defined, which defineswhether the reason code is visible to the customer 302, 304, 306 or onlyto the vendor's internal personnel.

[0038] After an appropriate reason code is selected by the customer 302,304, 306 or the internal AR personnel, a user interface specific to theselected reason code is dynamically built and displayed to therequesting party. Indeed, each reason code S2 a 1, S2 a 2, S2 a 3, S2 a4, S2 b 1, S2 b 2 (and any other reason code that may have been added)may be mapped to a separate user interface that prompts the user toenter the information relevant to the selected reason code, as shown atS4. Moreover, based upon the selected reason code, certain fields withinthe displayed user interface may be populated. For example, if theselected reason code is freight charges, the value(s) of the disputedfreight charge(s) may be imported form the disputed invoice into theCredit Memo Request being created. After the customer 302, 304, 306 orthe internal AR personnel has entered the requested information in theuser interface mapped to the selected reason code, a Credit Memo Requestmay be generated, as shown at S5. Thereafter, the generated Credit MemoRequest is validated (checked to insure that all mandatory informationhas been provided, for example), and assigned a unique identifier (fortracking purposes) such as a sequential number, as shown at S6. Thevalidated Credit Memo Request may then be displayed for the requestingparty; that is, the customer 302, 304, 306 or the internal AR personnel(such as 116 in FIG. 1). The requesting party may then verify theaccuracy of all information appearing on the Credit Memo Request, asshown at S7. If any of the information is incorrect, the requestingparty may be given the opportunity to correct or re-enter the inaccurateinformation by being sent back to step S2 a to select a more fittingreason code or to step S4 to re-enter any inaccurate information in theuser interface mapped to the selected reason code prior to re-submittingthe corrected Credit Memo Request. Once the Credit Memo Request issubmitted, appropriate tables within the database 110 may be populatedwith the Credit memo Request information of the validated and submittedCredit Memo Request.

[0039] When the information appearing the Credit Memo Request is deemedcorrect by the requesting party and the Credit Memo Request issubmitted, a Credit Memo Workflow specific to the selected reason codeis generated, as shown at S8. According to the present invention, theworkflow engine defines and enforces the hierarchical routing of theCredit Memo Request as the Credit Memo Request is processed by thevendor. To enable such functionality, the deploying company mustpre-define the hierarchy and routing for each type of Credit MemoRequest. The hierarchy and routing may be the same for all Credit MemoRequests, irrespective of the selected reason code, or the hierarchy androuting may be different for each type of Credit Memo Request, dependingupon the selected reason code. For example, the processing of CreditMemo Requests wherein the selected reason code indicates that it isbased upon disputed freight charges will be routed differently thanCredit Memo Requests based a “Duplicate Invoice” reason code. Indeed,the CMR based upon disputed freight charges may be routed to that personor persons in the vendor's AR department having responsibility forfreight charges, whereas a CMR based upon a claim of duplicate invoicemay be automatically granted upon verifying that the disputed invoice isindeed identical to another invoice for that same customer 302, 304,306. The hierarchy established for each reason code may list personshaving varying authorization levels; a higher placed person in thehierarchy may have the authority to approve a CMR for a higher amountthan a lower-placed person in the hierarchy. Moreover, each person inthe defined hierarchy may have to “sign off” on the Credit Memo Requestin order for the CMR to be granted. In this manner, the workflow enginefor that reason code may shepherd the generated CMR through itsdesignated route through the pre-established hierarchy, thereby ensuringthat the CMR approval process for that reason code is enforced. Thus,the approval/disapproval process for each generated CMR is constrainedby the workflow, thereby ensuring that all prescribed approvals areobtained in a timely manner. Built-in escalation features may be definedin each workflow, the CMR being forced to the next level in thehierarchy or to the next step in the process upon the failure of anypreceding step, again insuring that all submitted CMRs are processed ina timely manner.

[0040] As shown in step S9, the disputed invoice may be marked with anotice that a CMR is pending there against, preferably with the notationthat the Credit Memo Request is but a request until it is approved andbecomes a full-fledged Credit Memo. In this manner, the customer 302,304, 306 may be assured that a CMR has been generated and is pendingagainst the disputed invoice or account.

[0041] A notification may be generated as shown in step SI 0, to notifyone or more selected AR personnel of the deploying company (the vendor)of the generation of the Credit Memo Request. Such a selected ARpersonnel may include, for example, the collector assigned to thataccount is and/or the sales person listed on the disputed invoice. Sucha notification may include an email to the collector and/or to otherselected persons within vendor's organization and/or an entry in aninternally accessible Web notification page. In this manner, thecollector having charge of the customer's account, upon checking the Webnotification page, would note the presence of a new CMR and would havethe ability to click thereon to cause the underlying details of the CMRto be displayed.

[0042] If, after the CMR approval process is finished (step S11), theCredit Memo Request is disapproved as shown in step S12, the customer302, 304, 306 is notified as shown in step S16, optionally including thereasons for the disapproved CMR in the notification. The notification,according to a preferred embodiment, is sent by email, although othernotification means may be implemented. If, however, the CMR is approved,as shown at S13, a Credit Memo (CM) is automatically generated,advantageously without any intervention or manual entry from the vendor.Once the Credit Memo is generated, the underlying invoice and/or accountis preferably automatically credited for the amount in dispute and therequesting party notified, as shown at S16. As the status of eachinvoice is updated in real time and accessible to the users (whetherinternal or external to the vendor), the requesting party may displaythe disputed invoice or account and verify first hand that the requestedCredit Memo has been processed and that the disputed amount(s) has beencredited to the proper invoice and/account.

Hardware Description

[0043]FIG. 5 illustrates a block diagram of a computer system 500 withwhich an embodiment of the present invention may be implemented.Computer system 500 includes a bus 501 or other communication mechanismfor communicating information, and a processor 502 coupled with bus 501for processing information. Computer system 500 further comprises arandom access memory (RAM) or other dynamic storage device 504 (referredto as main memory), coupled to bus 501 for storing information andinstructions to be executed by processor 502. Main memory 504 also maybe used for storing temporary variables or other intermediateinformation during execution of instructions by processor 502. Computersystem 500 also includes a read only memory (ROM) and/or other staticstorage device 506 coupled to bus 501 for storing static information andinstructions for processor 502. A data storage device 507, such as amagnetic disk or optical disk, is coupled to bus 501 for storinginformation and instructions. A communication device 508, such as amodem or network (such as Ethernet, for example) card is also coupled tothe bus 501 to provide access to a network, such as shown at 112 in FIG.1 and 308 in FIG. 3.

[0044] The computer system 500 may also be coupled via bus 501 to adisplay device 521, such as a cathode ray tube (CRT), for displayinginformation to a computer user. An alphanumeric input device 522,including alphanumeric and other keys, is typically coupled to bus 501for communicating information and command selections to processor 502.Another type of user input device is cursor control 523, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 502 and for controllingcursor movement on display 521.

[0045] The present invention is related to the use of computer system500 to implement methods and systems for self-service AR management,according to the present invention. According to one embodiment thereof,the system for self-service AR management is provided by one or morecomputer systems 500 in response to processor(s) 502 executing sequencesof instructions is contained in memory 504. Such instructions may beread into memory 504 from another computer-readable medium, such as datastorage device 507. Execution of the sequences of instructions containedin memory 504 causes processor(s) 502 to implement the methods disclosedherein. In alternative embodiments, hard-wired circuitry may be used inplace of or in combination with software instructions to implement thepresent invention. Thus, the present invention is not limited to anyspecific combination of hardware circuitry and software.

[0046] While the foregoing detailed description has described preferredembodiments of the present invention, it is to be understood that theabove description is illustrative only and not limiting of the disclosedinvention. Those of skill in this art will recognize other alternativeembodiments and all such embodiments are deemed to fall within the scopeof the present invention. Thus, the present invention should be limitedonly by the claims as set forth below.

What is claimed is:
 1. A computer-implemented and Internet-based methodof managing Accounts Receivable (AR) information, comprising the stepsof: receiving a customer request for remote Internet access to ARinformation that is owned by a deploying company; retrieving thecustomer's AR information from a database and enabling the retrieved ARinformation to be remotely displayed for the customer; enablingpersonnel at the deploying company to retrieve and display thecustomer's AR information at any time, even simultaneously as the ARinformation is displayed for the customer.
 2. The method of claim 1,wherein the AR information is displayed on a World Wide Web (Web)browser.
 3. The method of claim 1, further comprising the step ofenabling keyword searching of the AR information stored in the databasethrough a Web browser to retrieve any information stored in the databasethat matches an entered search criteria, irrespective of a category inwhich the information is stored in the database.
 4. The method of claim3, wherein the keyword searching allows restricted searching based on atleast one of amount range, date range, due date range, category,customer, customer location, applied payments, open items, closed items,pending items, Credit Memo Requests, Credit Memos, a document number andany data categorization the database.
 5. The method of claim 3, whereinthe keyword searching across all customer AR information is restrictedto personnel of the deploying company.
 6. The method of claim 1, whereinthe retrieved AR information includes invoice information that isoptimized for printing in a format that matches a format of acorresponding paper invoice.
 7. The method of claim 1, furthercomprising the step of restricting access to the AR information by thepersonnel of the deploying company to selected personnel.
 8. The methodof claim 7, wherein the selected personnel includes collectors,accountants, AR personnel of the deploying company and sales personnel.9. The method of claim 1, further comprising the step of enablingcustomers to dispute one of all and a portion of an invoice and tocreate and submit a Credit Memo Request.
 10. The method of claim 9,further comprising the step of providing a plurality of reason codes fordisputing the invoice, each of the reason codes being mapped to acorresponding user interface, the user interface displaying onlyinformation specific to its corresponding reason code.
 11. The method ofclaim 10, wherein each of the reason codes includes a flag thatdetermines whether the reason code is visible only to personnel of thedeploying company.
 12. The method of claim 11, wherein the reason codesvisible only to the personnel of the deploying company includebankruptcy and goodwill.
 13. The method of claim 10, wherein the reasoncodes visible to the customers include freight, tax, shipping, duplicateinvoice and specific invoice line.
 14. The method of claim 9, whereinthe method implements a workflow engine, the workflow engine definingand enforcing a hierarchical routing of the Credit Memo Request as theCredit Memo Request is processed by the deploying company.
 15. Themethod of claim 9, further comprising the step of automaticallygenerating a Credit Memo Request and updating the customer's ARinformation in real time when the Credit Memo Request is approved. 16.The method of claim 14, wherein the workflow engine carries out a stepof notifying at least one of the customer and selected personnel of thedeploying company when the Credit Memo Request is approved and acorresponding Credit Memo is generated.
 17. The method of claim 16,wherein the notifying step is carried out by at least one of email andby updating a Web site.
 18. The method of claim 9, further comprisingthe step of marking an invoice against which a Credit Memo Request hasbeen submitted.
 19. The method of claim 1, wherein the customer requestfor remote access includes customer authentication data.
 20. The methodof claim 1, wherein the retrieved and displayed customer AR informationincludes a summary screen summarizing the customer's AR information. 21.The method of claim 20, further comprising the step of hyperlinking atleast some of the summarized AR information on the summary screen toenable the customer to view detailed AR information corresponding thehyperlinked summarized AR information.
 22. The method of claim 1,wherein the retrieved and displayed AR information includes informationrelated to at least one of invoices, payments, Credit Memos applied to aparticular invoice, Credit Memos applied to an entire customer accountand Credit Memo Requests.
 23. The method of claim 1, wherein thedisplayed AR information is dynamically sortable and wherein the methodfurther comprises the step of sorting and re-displaying the displayed ARinformation.
 24. The method of claim 1, wherein an appearance of thedisplayed AR information is customizable to match a corporate identityof the deploying company.
 25. The method of claim 1, wherein thedisplayed AR information includes a first portion and a second portion,the first portion displaying static AR information including customername, customer number and the second portion displaying dynamic ARinformation that changes depending upon an action by the customer. 26.The method of claim 25, wherein the second portion is adapted to includeinvoice information and configurable messages from the deployingcompany.
 27. The method of claim 1, further comprising the step ofdisplaying a button along with the displayed AR information, whereinclicking on the button causes all activities associated with a currentlydisplayed item to be displayed.
 28. Computer-implemented andInternet-based method of disputing an invoice from a vendor to acustomer, comprising the steps of: accessing a database recordcorresponding to the invoice to be disputed over a Web site of thevendor; selecting a reason code for the dispute along with anidentification of a disputed amount; validating a Credit Memo Requestincorporating the selected reason code and the disputed amount to createa pending Credit Memo Request; causing the Credit Memo Request to besent to and routed through at least one of a selected process for theselected reason code, a selected hierarchy of persons empowered toapprove Credit Memo Request incorporating the selected reason code and aprimary approver for the selected reason code; receiving a notificationupon approval or rejection of the pending Credit Memo Request, thedisputed amount being automatically credited to the disputed invoicewhen the pending Credit Memo Request is approved.
 29. The method ofclaim 28, wherein the selecting step selects a reason code from among agroup of reason codes including freight charges, taxes, shippingcharges, duplicate invoice, specific invoice line and at least onevendor-defined reason code.
 30. The method of claim 28, wherein when theselected reason code does not fit a reason for requesting the CreditMemo, the selecting step further includes a step of adding explanatorycomments to a blank field, thereby enabling the established hierarchy ofpersons empowered to approve the validated Credit Memo Request and theprimary approver for the selected reason code to process the Credit MemoRequest.
 31. The method of claim 28, wherein the validating stepincludes a step of submitting the Credit Memo Request if the Credit MemoRequest is correct and includes the step of correcting the Credit MemoRequest if any information appearing thereon is incorrect.
 32. Themethod of claim 28, wherein the validating step includes a step ofdisplaying the Credit Memo Request for the customer and giving thecustomer a first option to submit the Credit Memo Request to execute thecausing step and a second option to return to an earlier screen tocorrect any incorrect information on the Credit Memo Request.
 33. Themethod of claim 28, wherein the reason codes, process, hierarchy andprimary approver are defined by the vendor upon enabling thecomputer-implemented method.
 34. The method of claim 28, furthercomprising a step of authenticating a customer before allowing thecustomer to carry out the accessing step.
 35. The method of claim 28,further including a step of accessing a current status of the pendingCredit Memo request in real time.
 36. The method of claim 28, furtherincluding a step of marking the disputed invoice with a legend orindicia indicating that a Credit Memo Request is pending there against.37. An Internet-based electronic system for enabling remote access andmanagement of Accounts Receivable (AR) information of a deployingcompany, the system comprising: a database that configured to store theAR information; a first computer arranged to receive a customer requestfor remote Internet access to the AR information, to retrieve the ARinformation from the database upon receiving the customer request and toenable the retrieved AR information to be remotely displayed for therequesting customer; a second computer arranged to enable personnel atthe deploying company to retrieve and display the customer's ARinformation simultaneously as the AR information is displayed for thecustomer.
 38. The system of claim 37, wherein the AR information isdisplayed on each of the first and second computers using a World WideWeb (Web) browser.
 39. The system of claim 37, wherein each of the firstand second computers are further arranged to carry out keyword searchingof the database through a Web browser to retrieve any information storedin the database that matches an entered search criteria, irrespective ofa category in which the information is stored in the database.
 40. AnInternet-based electronic system for disputing an invoice from a vendorto a customer, the system comprising: a database configured to store theinvoice; a computer adapted to connect to the Internet; a Web site, theWeb site being controlled by the vendor and accessible by the computer,the Web site being configured to allow a customer using the computer toremotely access the invoice and to dispute the invoice by: selecting areason code for the dispute and at least a disputed amount; validating aCredit Memo Request incorporating the selected reason code and thedisputed amount to create a pending Credit Memo Request, and causing theCredit Memo Request to be sent to be processed through a workflow engineto send and route the Credit Memo Request through at least one of aselected process for the selected reason code, a selected hierarchy ofpersons empowered to approve Credit Memo Request incorporating theselected reason code and a primary approver for the selected reasoncode.
 41. The system of claim 40, wherein the workflow engine is furtherconfigured to send a notification upon approval or rejection of thepending Credit Memo Request, the disputed amount being automaticallycredited to the disputed invoice when the pending Credit Memo Request isapproved.
 42. The system of claim 40, wherein the Web site is furtherconfigured to allow the customer to add explanatory comments to a blankfield, to enable the selected hierarchy of persons empowered to approvethe validated Credit Memo Request and the primary approver for theselected reason code to process the Credit Memo Request when theselected reason code does not fit a reason for requesting the CreditMemo Request.
 43. The system of claim 40, wherein the Web site isfurther configured to allow a submission of the Credit Memo Request ifthe Credit Memo Request is correct and the correction of the Credit MemoRequest if any information therein is incorrect.
 44. The system of claim40, wherein the reason codes, process, hierarchy and primary approverare adapted to be predefined by the vendor.
 45. The system of claim 40,wherein the Web site is further configured to authenticate a customerbefore allowing the customer to access the invoice.
 46. The system ofclaim 40, wherein the Web site is further configured to enable real timeaccess to a status of the pending Credit Memo request.
 47. The system ofclaim 40, wherein the Web site is further configured to mark thedisputed invoice with a legend or indicia indicating that a Credit MemoRequest is pending there against.